1. Field of the Invention
This invention relates generally to computer networking, and more particularly to a common hardware interface for communication within a Fibre Channel network environment.
2. Description of the Related Art
Conventionally, to provide an interface to hardware devices, software designers often utilize device drivers designed for specific hardware devices. A device driver is a named entity that supports basic I/O functions, such as read, write, get configuration, and set configuration, and typically, also uses and manages interrupts from a device as well.
A device driver is used to provide access to a device from application code in as general purpose a fashion as reasonable, while being as efficient as possible. The interface for a device driver typically is generic and device driver independent, however, the actual driver implementation is completely up to the device driver designer.
As mentioned above, most device drivers are concerned with the movement of information, for example data bytes along a serial interface, or packets in a network. Interrupts typically are used in order to make the most efficient use of system resources, which allows for other application processing to take place while the data transfers are underway, with the interrupts used to indicate when various events have occurred.
For example, a serial port typically generates an interrupt after a character has been sent “down the wire” and the interface is ready for another. While the data is being sent, further application processing should be allowed since the data transfer can take quite a long time. To allow further application processing, an interrupt is generally used to “alert” the driver and allow the driver to send a new character as soon as the current one is complete, without any active participation by the application code.
One of the first storage and interconnect technologies to utilize device drivers was the Small Computer Systems Interface (SCSI), which is an intelligent, parallel I/O bus on which various peripheral devices and controllers exchange information. Because of its longevity in the marketplace, the parallel SCSI provides a large depth and breadth of products, which include SCSI disk drives, CD-ROM, RAID subsystems, scanners, and other products that are available from a multitude of sources.
To obtain the benefits of the SCSI I/O performance, computer systems use SCSI controllers. A SCSI controller is a hardware device that provides communication with a SCSI network. Communication with the SCSI controller generally is accomplished using a SCSI device driver.
FIG. 1 is a block diagram showing a prior art SCSI system 100. The SCSI system 100 includes an application program 102, a SCSI controller 108, SCSI drives 110, and a SCSI device driver comprising an operating system module (OSM) 104 and a common hardware interface module (CHIM) 106. As explained in greater detail subsequently, typically the OSM is operating system dependent, while the CHIM is operating system independent.
During operation the application program 102 executes on a particular operating system, such as WINDOWS 95, and accesses networked SCSI devices, such as the SCSI drives 110, using the SCSI device driver. Specifically, when the application program 102 requires access to a SCSI device, such as the SCSI drives 110, the application program 102 passes a device access command to the SCSI device driver via the OSM 104 section of the SCSI device driver.
Since the OSM 104 is operating system dependent, the OSM 104 varies depending on the type of operating system the application 102 is executing on. Hence, to use the OSM 104 in combination with an application 102 executing on a NT4.0 operating system, the OSM should be designed specifically for the NT4.0 operating system. As shown in FIG. 1, the OSM 104 can be designed as a NT4.0 OSM 112, a WINDOWS 95 OSM 114, a Linux OSM 116, a VX Work OSM 118, a MAC OSM 120, or any other operating system OSM. In this example, since the application 102 is executing on a WINDOWS 95 operating system, the OSM 104 would actually be a WINDOWS 95 OSM 114.
When the OSM 104 receives the operating system specific device access command, the OSM 104 translates the command into an operating system independent CHIM device access command for the common hardware interface module (CHIM) 106 portion of the SCSI device driver, and passes the translated command to the CHIM 106.
Thus, an OSM 104 is written for a specific operating system and completely isolates the CHIM 106 from the host operating system. Typically, the OSM 104 presents device driver entry points that are specific to the particular operating system and converts them to operating system independent calls to the CHIM 106. Thus, when the operating system calls the driver's initialization entry points, the OSM 104 makes a series of calls to the CHIM 106 that allow the CHIM 106 to check for the presence of adapter hardware, initialize the adapter, and access connected devices.
The CHIM 106 is an operating system independent common hardware interface module that receives CHIM commands and translates the CHIM commands into commands for the SCSI controller 108.
Whereas the OSM 104 isolates the CHIM 106 from the operating system, the CHIM 106 isolates the OSM 104 from the SCSI controller 108 hardware. The CHIM 106 initializes the SCSI controller 108 hardware, builds commands in the correct format for the adapter, and performs command delivery.
In use, The OSM 104 provides a protocol-specific command, such as a SCSI Command Descriptor Block (CDB), to the CHIM 106. After receiving the command from the CHIM 106, the SCSI controller 108 accesses the SCSI drives 110 using the SCSI protocol.
The problem with the prior art SCSI system 100 is that SCSI protocol is often not fast enough to support many modern application needs. The limitations for SCSI in terms of bus speed, reliability, cost, and device count are leading systems and storage designers to look toward serial device interfaces that feature higher data transfer rates.
One such serial device interface is Fibre Channel, which provides a high-speed data transfer interface that can be used to connect systems and storage in point-to-point, switched, or Loop topologies. In addition, the Fibre Channel Arbitrated Loop can support copper media and loops having 126 devices, or nodes.
FIG. 2 is a block diagram illustrating a conventional Fibre Channel system 200. The Fibre Channel system 200 includes a Port Driver 202, a Fibre Channel driver 204, a Fibre Channel controller 206, and a network device 208. In use, the port driver passes device access commands to the Fibre Channel driver 204, which facilitates communication between the port driver 202 and the Fibre Channel controller 206.
The Fibre Channel driver 204 operates similar to the device drivers discussed previously. Broadly speaking, the Fibre Channel driver 204 provides access to the Fibre Channel controller 206 in as general purpose a fashion as reasonable while being as efficient as possible. Generally, the Fibre Channel controller 206 accesses the network device 208 using a Fibre Channel protocol.
In a Fibre Channel Arbitrated Loop configuration, when a device is ready to transmit data, the device initially arbitrates and gains control of the Loop. Typically, the device accomplishes this by transmitting an Arbitrate (ARBx) Primitive Signal, where x=the Arbitrated Loop Physical Address (AL_PA) of the device. Once a device receives its own ARBx Primitive Signal, the device has gained control of the Loop and can then communicate with other devices by transmitting an Open (OPN) Primitive Signal to a destination device. Once this happens, there essentially exists point-to-point communication between devices.
If more than one device on the Loop is arbitrating at the same time, the x values of the ARB Primitive Signals are compared. When an arbitrating device receives another device's ARBx, the ARBx with the numerically lower AL_PA is forwarded, while the ARBx with the numerically higher AL_PA is blocked. Thus, the device with the lower AL_PA generally gains control of the Loop first. Then, once the device relinquishes control of the Loop, the other device can gain control of the Loop.
Unlike token-passing schemes, there generally is no limit on how long a device may retain control of the Loop. This demonstrates the “channel” aspect of Fibre Channel. There is, however, an optional Access Fairness Algorithm, which prohibits a device from arbitrating again until all other devices have had a chance to arbitrate.
In addition to Fibre Channel's strong channel characteristics, Fibre Channel also provides powerful networking capabilities, allowing switches and hubs to enable the interconnection of systems and storage into tightly-knit clusters. These clusters are capable of providing high levels of performance for file service, database management, or general purpose computing. Moreover, because Fibre Channel is able to span 10 kilometers between nodes, Fibre Channel allows the very high speed movement of data between systems that are greatly separated from one another.
Because of Fibre Channel's superior performance and networking capabilities, and Fibre Channel's broad industry support, Fibre Channel is in great demand. However, one problem with Fibre Channel is that many networks are currently configured for use with a SCSI protocol. Thus, in addition to physical connections, the overlying network software typically must be replaced to convert these networks to Fibre Channel. However, the cost of designing a completely new software system and replacing old software systems is tremendous.
Further, since conventional drivers are often separated into individual code modules, when one module of a driver is upgraded or further developed, the other module should be treated as a “black box” by the module developer. However, there are occasions when a developer of an OSM may need to configure characteristics of the controller that are generally only accessible by another module. But, developers of conventional drivers are generally unable to configure these characteristics while still treating the other code module as a “black box.” As a result, developers of conventional drivers often need to alter the values in the other code module directly in order to configure a controller. This presents development problems since designers must determine the complete inner workings of separate code modules and often introduce errors into these code modules because of their unfamiliarity with the code.
In view of the forgoing, there is a need for a Fibre Channel interfacing system that is capable of being incorporated into existing SCSI software networks with little additional cost. In addition, the system should allow driver development while allowing separate code modules to remain “black boxes” to each other. Thus, developers of one driver code module should be allowed to configure controller parameters that are generally only accessible by other driver modules while still treating the other driver module as a “black box.”